From 784b3edfaa6e9f1e8dd28156f92d72be9a64094f Mon Sep 17 00:00:00 2001 From: "kfraser@localhost.localdomain" Date: Tue, 27 Mar 2007 19:05:48 +0100 Subject: [PATCH] hvm svm: Do not deliver virtual interrupts concurrently with virtual exceptions. Signed-off-by: Keir Fraser --- xen/arch/x86/hvm/svm/intr.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/xen/arch/x86/hvm/svm/intr.c b/xen/arch/x86/hvm/svm/intr.c index 262f366838..89f3f30912 100644 --- a/xen/arch/x86/hvm/svm/intr.c +++ b/xen/arch/x86/hvm/svm/intr.c @@ -67,6 +67,20 @@ asmlinkage void svm_intr_assist(void) int intr_type = APIC_DM_EXTINT; int intr_vector = -1; + /* + * Do not deliver a virtual interrupt (vintr) if an exception is pending. + * This is because the delivery of the exception can arbitrarily delay + * the injection of the vintr (for example, if the exception is handled + * via an interrupt gate, hence zeroing RFLAGS.IF). In the meantime the + * vTPR can be modified upwards and we can end up delivering the vintr + * when it is not in fact valid to do so (because we do not re-check the + * vTPR value). Moreover, the guest will be able to see the updated + * APIC/PIC state (as if the interrupt had been acknowledged) yet will not + * have actually received the interrupt. This could confuse the guest! + */ + if ( vmcb->eventinj.fields.v ) + return; + /* * Previous Interrupt delivery caused this intercept? * This will happen if the injection is latched by the processor (hence -- 2.30.2